In recent years, downloading multimedia content to one's mobile station has become commonplace. Verizon Wireless's virtual store, or “VStore,” is a web application that provides customers a browser interface on their feature phones, smart mobile phones and advanced mobile phones for various storefronts, for example, stores offering tones, games and tools and applications, by providing a categorized display of device-specific content types. Users can access each of these stores to browse through the categories and view the details of the items and purchase them.
Apart from the traditional way of accessing these storefronts, businesses also wanted a direct way of providing access to specific items as a part of promotions and regular advertisements. Based on the business requests, a specific URL pattern was established which would be recognized by the browser application to allow faster access to the storefront. By using this URL, businesses can construct different dynamic URLs in the specified format if the item details are known. The application is made capable of handling all such URLs after establishing their origin and proper authentication. The URLs corresponding to specific items of promotion will be advertised in the ad space on other mobile browser applications and portals. When customers click on the ads, the request is specifically directed to the item detail page of the item being promoted and users can then simply purchase the item with one click without going through the hassles of starting from category level and digging down to specific items. URL links such as those described to are often referred to as “deep linking URLs.” In short, it is a “one click” process to purchase something that the user likes.
Different types and/or different generations of mobile stations implement a variety of different browsers and related applications for the user interface to on-line content, including on-line stores. In order to execute the “one click” process using the existing application architecture, each of the mobile stations must be provided a URL that is specific to that station's browser platform.
Feature phones, for example, use Java technologies, while smart phones and advanced phones use different portal technologies. It is desirable that the URL content be displayed the same way regardless of user interface platform. However, in order to be displayed correctly, the link must be provided in the correct application format that is compatible with the user interface platform of the user's particular mobile station. As technology has improved, the mobile stations have developed more features and advanced capabilities. Because of this, different applications are used based on device category. This is in part because the later applications, such as those used on advanced phones, provide additional features and functionality not possible on older mobile stations, such as feature phones. For example, a WAP application is used for feature phones, an SMI application is used for smart phones, and MW3 application is used for advanced phones. The SMI application provides additional features that cannot be run on feature phones, while the MW3 application provides features that cannot be run on feature phones or advanced phones.
FIG. 5 is a flowchart of a process for routing and processing URL requests received from three different types of mobile stations using user interface platform specific URLs as executed in the prior art. In FIG. 5, the customer launches the browser on the mobile station and the browser provides a default home page URL for the browser. For example, for a mobile service provider whose system support all three types of phones, the browser may point to a different starting page for each category of phone. For example, for Verizon, the URL on feature phones points to MW2.0 portal, to a VZStart page for some smart phones built on IBM portal server, and to MW3.0 portal for a large variety of new advanced devices. Sales and marketing ads can feature on any of these portal pages or applications. When the user clicks on an ad (that points to a specific promotional item), the request hits the web server that front-ends the specific application that supports the device category the request originated from. Each device category has a specific link that directs it to a different application server based on the application required by the device.
For example, if the user was to click on the ad from a feature phone at step 5S1a, the link would send the request through network directly to a WAP application at step 5S2a. If the URL link was clicked from a smart phone at step 5S1b, the request would be sent through the network directly to a SMI application at step 5S2b. Finally, if the URL request was sent from an advanced phone at step 5S1c, the request would be sent through the application directly to the MW3 server at step 5S2c. In each case, the request will be processed by the application supported by the user interface platform used by the particular mobile station at steps 5S3a, 5S3b, or 5S3c, respectively, in order to obtain the relevant content in the appropriate format for the mobile station. The content is then sent back to the mobile station to be displayed at steps 5S4a, 5S4b, or 5S4c. Using this process, a URL specific to either the WAP application, SMI application, or MW3 application is provided to each phone such that the request is directed to the specific application supported by the user interface platform allowing the user to access to that specific item detail page of “VStore” directly and so that the user may view it in the correct format.
Although this “One-Click” process is useful to the customer, implementing the process is more complicated for those providing the links. In order to provide the content in a consistent format independent of the browser platform, a different link must be provided for each browser platform such that three different links are required to access the same content. Given that each link is used to access a specific piece of content, such as a particular song or ring tone, having to provide browser specific links increases the amount of work significantly. Further as additional browser platforms develop, work will be required in order to display the URL correctly on all feature devices as well as those already in existence.
Hence a need exists for a way to provide browser content to all mobile stations in a format compatible with the mobile station's user interface platform using a one URL link that may be used by various mobile stations independent of the mobile stations' browser platforms.